книги хакеры / журнал хакер / специальные выпуски / Специальный выпуск 58_Optimized

Ðèñ. 4. OllyDebugger

Рис. 5. Профессионально ориентированный отладчик Soft-ice

Рис. 2. Консольная версия IDA PRO

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

to

w Click

m

w

w

df-xchan

o

НЕОБХОДИМЫЙ ИНСТРУМЕНТАРИЙ

.

.c

p

g

e

Голыми руками много дыр не наловишь! Агрессивная природа двоичного кода требует применения специального инструментария. Прежде всего потребуются дизассемблеры. Их много, но IDA PRO бесспорный лидер, оставляет своих конкурентов далеко позади и поддерживает практи- чески все форматы исполняе-

мых файлов, процессоры и компиляторы, существующие на сегодняшний день (см. рис. 2).

Еще понадобится отладчик. Классический выбор – Soft-ice (см. рис. 4), однако в последнее время его жирная туша начинает уступать маленькому и подвижному OllyDebugger'у (см. рис. 5), главная вкусность которого – автоматическое отображение распознанных

ASСII-строк рядом со смещениями, что значительно упрощает поиск переполняющихся буферов, поскольку они становятся видны как на ладони. К сожалению, будучи отладчи- ком прикладного уровня, OllyDebugger не может отлаживать ядерные компоненты Windows (некоторые серверные процессы в том числе).

Рис. 3. Дизассемблер под Palm PC

Если исследуемая программа упакована, перед началом дизассемблирования ее следует распаковать, что можно сделать любым универсальным дампером (Proc Dump, PETools, Lord-PE), а еще лучше – специализированным распаковщиком, знающим данный упаковщик в лицо (правда, не для всех упаковщиков суще-

ствуют распаковщики). Дампы, снятые с программы, чаще всего неработоспособны и для своего запуска требуют серьезной доработки напильником. Однако зачем запускать их? Для дизассемблирования они подойдут и так.

Все вышеупомянутые продукты можно найти в Осле (Donkey) или в Муле (Mule) – файлообменных сетях, грубо говоря, представляющих собой интернет внутри интернета. С их появлени-

ем поиски вареза на WEB'е стали уже неактуальны (удивительно, но о существовании осла многие до сих пор не знают!).

29

оказаться слишком абстрактной и непонятной.

ОШИБКИ ПЕРЕПОЛНЕНИЯ

Любая программа в значительной мере состоит из библиотек, анализировать которые бессмысленно: они уже давным-давно проанализированы, и никаких радикально новых дыр здесь нет. К тому же подавляющее большинство библиотек распространяется вместе с исходными текстами, так что корпеть над их дизассемблированием вдвойне ненужно. Как правило, библиотечный код располагается позади основного кода программы,

èотделить его достаточно просто. Сложнее идентифицировать имена библиотечных функций, без знания которых мы конкретно завязнем в простыне дизассемблерных листингов, словно в трясине. К счастью, подавляющее большинство стандартных библиотек автоматически распознаются Идой. Сигнатуры же экзоти- ческих библиотек от сторонних производителей в любой момент можно добавить и самостоятельно, благо IDA допускает такую возможность (подробности в "Hacker Disassembling Uncovered" by Kris Kaspersky и штатной документации).

Решение о загрузке той или иной сигнатурной базы принимается IDA на основе анализа стартового кода, и "чужеродные" библиотеки рискуют остаться нераспознанными. То же самое происходит и при загрузке дампов памяти с поврежденным или отсутствующим стартовым кодом или неверно установленной Entry Point (хроническая болезнь всех дамперов). Поэтому, если большая часть функций программы осталась нераспознанной (см. рис. 7), попробуй подключить сигнатурную базу вручную, выбрав в меню File\Load file пункт FLIRT Signature file. Появится обширный перечень известных Иде библиотек (см. рис. 9). Какую из них выбрать? Если ты новичок в дизассемблировании и нужную библиотеку не удается отождествить "визуально", действуй методом перебора, загружая одну сигнатуру за другой, добиваясь максимального расширения голубой заливки (см. рис. 8)

Просматривая список распознанных

èимпортируемых функций, отберем самые опасные из них. В первую оче- редь к ним относятся функции, принимающие указатель на выделенный буфер и возвращающие данные заранее не предсказуемого размера (например sprintf, gets и т.д.). Функции с явным ограничением предельно допустимой длины буфера (fgets, GetWindowText, GetFullPathName) намного менее опасны, однако никаких гарантий их лояльности ни у кого нет. Очень часто программист выделяет буфер размером намного меньше и предохранительный клапан не срабатывает. Примера в листинге 1. Очевид- »

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha				S E C U R I T Y - Ô Î Ê Ó Ñ Û

При поиске переполняющихся буферов методом слепого перебора тестируй различные длины строк, а не только строки запредельной длины, поскольку материнские функции могут ограни- чивать их размер сверху, образуя узкий коридор.

Просматривая HEX-дамп, обращай внимание на недокументированные ключи (чаще всего они записаны прямым текстом): некоторые из них позволяют обойти систему безопасности и сделать с программой непредусмотренные вещи.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
	S E C U R I T Y - Ô Î Ê Ó Ñ Û			-xcha

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

30

КЛИЕНТ

ULTIMATE ADVENTURE

BUY

w Click

to

m

w

но, если пользователь введет с кла-

ПРЕЖДЕ ЧЕМ НАЧАТЬ…

w

o

.

df

n

e

p

.c

-x cha

g

виатуры строку в 100 и более байт, то

произойдет неминуемое переполне-

Существуют различные подходы к исследованию двоичного ко-

ние буфера и никакие ограничители

да. Методики слепого поиска не предполагают ничего, кроме мето-

длины не спасут! Но это уже лирика.

дичного перебора различных комбинаций входных данных (кото-

Полный перечень потенциально

опасных функций занимает слишком

рыми, как правило, являются строки различной длины, используе-

много места, поэтому здесь не приво-

мые главным образом для выявления переполняющихся буферов).

дится. Будем учиться действовать по

Целенаправленный анализ требует глубоких знаний системы, нет-

обстоятельствам. Загружаем исследу-

ривиального мышления и богатого опыта проектирования "про-

емую программу в дизассемблер (луч-

мышленных" программных комплексов. Хакер должен наперед

ше всего в IDA PRO), нажимаем <Shift-

F3>, щелкаем мышью по колонке "L"

знать, что именно он ищет. Излюбленные ошибки разработчиков.

(сокращение от Library – библиотеч-

Вероятные места скопления багов. Особенности и ограничения

ная функция), отделяя библиотечные

различных языков программирования. Одних лишь навыков дизас-

функции от всех остальных. Достаем

семблирования (ты ведь умеешь дизассемблировать, не правда

с полки толстый том справочного ру-

ли?) для наших целей окажется катастрофически недостаточно.

ководства (для лицензионных поль-

зователей) или запускаем свой люби-

Естественно, тупой перебор не всегда приводит к положительному

мый MSDN (для всех остальных) и

результату и множество дыр при этом остаются незамеченными. С

смотрим на прототип каждой из пере-

другой стороны, изучение дизассемблерных листингов также не га-

численных здесь функций. Если сре-

рант успеха. Ты можешь просидеть за монитором многие годы, но

ди аргументов присутствует указа-

не найти ни одного достойного бага. Это уж как повезет или не по-

тель на буфер (что-то типа char*,

void*, LPTSTR и т.д.) и этот буфер при-

везет (что, кстати, намного вероятнее)… Поэтому, прежде чем при-

нимает возвращаемые функцией дан-

бегать к дизассемблированию, убедись, что все возможное и не-

ные, то почему бы не проверить, как

возможное уже сделано. Как минимум следует нанести массиро-

он относится к переполнению?

ванный удар по входным полям, засовывая в них строки непомер-

Нажимаем <Enter>, переходя к началу

ной длины, а как максимум – испробовать типовые концептуальные

функции, а затем входим в меню

View\Open Subview\Cross Reference, îòê-

уязвимости. В частности, если атакуемый брандмауэр беспрепят-

рывая окно с перекрестными ссылками,

ственно пропускает сильно фрагментированные TCP-пакеты, диз-

каждая из которых ведет к точке вызо-

ассемблировать его не нужно, суду и так все ясно: чтобы обнару-

ва нашей функции. В зависимости от

жить подобную дыру в двоичном коде, необходимо отчетливо

особенностей компилятора и сексуаль-

представлять механизм работы брандмауэра и заранее предпола-

ных наклонностей программиста, проек-

тировавшего исследуемое приложение,

гать ее существование. А раз так, то не проще ли будет самостоя-

вызов может быть как непосредствен-

тельно сформировать фрагментированный пакет и посмотреть, как

ным (типа CALL our_func), так и косвен-

на него отреагирует брандмауэр? Подложные пакеты – другое де-

íûì (òèïà mov ecx, pClass/mov ebx,[ecx +

ло. Отправляя их жертве, мы должны знать, какие именно поля про-

4]/call ebx/…/pClass DD xxx/DD offset

веряются, а какие нет. Без дизассемблирования здесь уже не обой-

our_func). В последнем случае перекре-

тись! Мы должны выделить код, ответственный за обработку заго-

ловков, и проанализировать критерии отбраковки пакетов. В ко-

нечном счете дизассемблер – всего лишь инструмент, и на роль ге-

нератора идей он не тянет. Бесцельное дизассемблирование – это

путь в никуда.

Рис. 7. Вид навигатора IDA PRO

Рис. 8. Теперь в Багдаде полный порядок!

Рис. 9. Перечень сигнатур, известных ИДЕ

Функции с явным ограничением предельно допустимой длины буфера (fgets, GetWindowText, GetFullPathName) намного менее опасны.

стные ссылки на out_func будут вести к DD offset our_func и определить место ее реального вызова будет не так-то просто! Обычно хакеры в таких случаях нанимают отладчик, устанавливая на our_func точку останова, а затем записывают EIP всех мест, откуда она вызывается (кстати, наличие интегрированного отладчика в последних версиях IDA существенно ускоряет этот процесс).

И вот мы находимся в окрестностях вызывающего кода! Если аргумент, определяющий размер принимаемого буфера, представляет собой непосре-

дственное значение (что-то типа push 400h, см. листинг 2) – это хороший знак, и дыра, скорее всего, ждет нас где-то поблизости. Если же это не так, не стоит отчаиваться: лучше, прокру- чивая курсор вверх, посмотреть, где этот размер инициализируется. Может быть, он все-таки представляет собой константу, передаваемую через более-менее длинную цепочку переменных или даже аргументов материнских функций!

Теперь найдем код, осуществляющий выделение памяти под буфер (обычно за это отвечают функции

ХАКЕРСПЕЦ 09(58) 2005

				hang		e
			C				E
		X
	-							d
	F									t
	D									i
										r
P						NOW!				o
					BUY
				to
w Click											m
w
	w									o
	.						g		.c
		p
			df			n		e
				-xcha

Рис. 10. Берем библиотечную функцию, прототип которой допускает возможность переполнения (1), и переходим по перекрестным ссылкам в окрестности ее вызова (2), смотрим на ограничитель предельно допустимой длины возвращаемых данных, сверяя его с размером выделяемого буфера (3), делаем вывод о возможности (или невозможности) переполнения

Законы безопасного проектирования гласят: прежде чем выделять буфер, определи точный размер данных.

malloc и new). Если аргумент, определяющий размер выделяемой памяти, также представляет собой константу, причем эта константа меньше предельно допустимой длины возвращаемых данных, дыра найдена и можно смело переходить к фазе анализа возможных способов воздействий на переполняющийся буфер через поля входных данных.

Законы безопасного проектирования гласят: прежде чем выделять буфер, определи точный размер данных, которые ты собираешься положить туда. Другими словами, в правильной программе вызову malloc или new всегда предшествует strlen, GetWindowTextLength или что-то типа того. В противном случае программа потенциально уязвима. Разумеется, наличие превентивной проверки размера само по себе еще не гарант стабильности, поскольку далеко не во всех случаях затребованный размер определяется правильно, особенно если в буфер сливаются данные с нескольких источников.

С локальными переменным в этом плане намного сложнее, поскольку их размер приходится явным образом задавать на этапе компиляции программы, когда длина возвращаемых данных еще не известна. Неудивительно, что переполняющиеся буфера чаще всего обнаруживаются именно среди локальных переменных.

Локальные переменные хранятся в стековых фреймах (англ. frames), также называемых кадрами или автоматической памятью. Каждой функции выделяется "персональный" кадр, в который помещаются все принадлежащие ей локальные переменные. Формирование кадра чаще всего осуществляется машинной командой "SUB ESP, xxx", реже – "ADD ESP,

31

–xxx", где xxx - размер кадра в байтах. Текущие версии IDA PRO по умолча- нию трактуют все непосредственные значения как беззнаковые числа, и преобразование "xxx" в " xxx" приходится осуществлять вручную путем нажатия на клавишу < – >.

К сожалению, "разобрать" монолитный кадр на отдельные локальные переменные в общем случае невозможно, поскольку компилятор полностью уничтожает исходную информацию и анализ становится неоднозначным.

Однако для наших целей возможностей автоматического анализатора IDA PRO более чем достаточно. Мы будем исходить из того, что локальные буфера чаще всего (но не всегда!) имеют тип byte *, а их размер составляет по меньшей мере 5 байт (правда, как показывает статистика, ошибки переполнения чаще всего встречаются именно в четырехбайтовых буферах, которые при беглом анализе легко спутать с DWORD).

Рассмотрим в качестве примера кадр стека, "разобранный" автомати- ческим анализатором IDA PRO, и попытаемся обнаружить в нем локальные буфера (см. листинг 3).

Переменная var_38 имеет тип DWORD и занимает 4 байта (размер переменной определяется путем вы- читания адреса текущей переменной из адреса следующей: –34h – (– 38h) == 4h). На буфер она похожа мало.

Переменная var_34 имеет тип BYTE и занимает 10h байт, что типично для локального буфера. То же самое можно сказать и о переменной var_20. Переменная var_24 хотя и имеет тип BYTE, занимает всего 4 байта, поэтому может быть как компактным локальным буфером, так и простой скалярной переменной (причем последние встречаются намного чаще). До

тех пор пока на предмет переполне- »

Рис. 11. Иерархия функций в графическом представлении

				hang		e
			C				E
		X
	-							d
	F								t
	D								i	r
P						NOW!			o
					BUY
				to
w Click											m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha				S E C U R I T Y - Ô Î Ê Ó Ñ Û

Следует помнить о том, что оптимизирующие компиляторы онлайнят функции memcpy/strcpy и memcmp/strcmp, непосредственно вставляя их тело в код! Ищи инструкции rep movs/rep cmps и исследуй их окрестности!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
	S E C U R I T Y - Ô Î Ê Ó Ñ Û			-xcha

Прежде чем искать дыры в подопытной программе, убедись, что их уже не нашли другие! Собери все известные на данный момент дыры и отметь их на карте дизассемблерного кода.

32 КЛИЕНТ ULTIMATEADVENTURE

ния не будут исследованы все явные буфера, возиться с подобными "кандидатами в буфера" нет никакого смысла.

Просматривая дизассемблерный код функции, найдем все ссылки на выявленный буфер и проанализируем возможные условия его переполнения.

Вот например:

ЛИСТИНГ 1. ПРИМЕР ПРОГРАММЫ, ПОДВЕРЖЕННОЙ ПЕРЕПОЛНЕНИЮ СО СРЫВОМ ПРЕДОХРАНИТЕЛЬНОГО КЛАПАНА

#define MAX_BUF_SIZE	100
#define MAX_STR_SIZE	1024

char *x; x = malloc(MAX_BUF_SIZE); fgets(x, MAX_STR_SIZE, f);

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

push	300
lea	eax, [ebp+var_34]
push	eax
call	_fgets
add	esp, 0Ch

Сразу видно, что переменная var_34 используется для хранения введенной строки (значит, это все-таки буфер!) с предельно допустимой длиной

â300h байт, при длине самой локальной переменной в 10h байт. Не исклю- чено, что var_34, var_24 и var_20 в действительности представляют собой "кусочки" одного буфера, однако

âданном случае это ничего не меняет, поскольку их совокупный размер намного меньше 300h!

Если же среди локальных переменных обнаружить переполняющиеся буфера несмотря на все усилия так и не удастся, можно попытать счастья среди развалин динамической памяти, отслеживая все перекрестные ссылки на функции типа new и malloc и анализируя окрестности их вызова.

Как бы там ни было, обнаружив переполняющийся буфер в одной из глубоко вложенных функций, не спеши радоваться: возможно, он никак не связан с потоком пользовательских данных, или (не менее неприятно) одна из материнских функций ограничивает предельно допустимую длину ввода сверху и переполнения не происходит. Пользователи графической версии IDA (фууу!) могут воспользоваться инструментом CALL GRAPH для просмотра дерева вызовов, уродливо отображающего взаимоотношения между дочерними и материнскими функциями и позволяющего (во всяком случае, теоретически) проследить маршрут передвижения введенных пользователем данных по программе. К сожалению, отсутствие каких бы то ни было средств навигации (нет даже простейшего поиска!) обесценивает все прелести CALL GRAPH'а, и сориентироваться в построенных им диаграммах просто нереально. Однако никто не запрещает разрабатывать адекватные средства визуализации самостоятельно.

Пока адекватный инструмент не готов, приходится иметь секс с отладчи- ком, причем не простой, а анальный.

История начинается просто. Заполняем все доступные поля пользовательского ввода, устанавливаем точ- ку останова на вызов считающей их функции (например recv), устанавливаем точки останова непосредственно на буфер, принимающий введенные нами данные, и затем ждем последую-

ЛИСТИНГ 2. НЕПОСРЕДСТВЕННОЕ ЗНАЧЕНИЕ МАКСИМАЛЬНОЙ ДЛИНЫ БУФЕРА, ПЕРЕДАВАЕМОЕ ФУНКЦИИ, ХОРОШИЙ ПРИЗНАК ВОЗМОЖНОГО ПЕРЕПОЛНЕНИЯ

.text:00401017	push				400h
.text:0040101C	mov				ecx, [ebp+var_8]
.text:0040101F	push				ecx
.text:00401020	call				_fgets

ЛИСТИНГ 3. ЛОКАЛЬНЫЕ ПЕРЕМЕННЫЕ, АВТОМАТИЧЕСКИ ВОССТАНОВЛЕННЫЕ IDA

.text:00401012 sub_401012 proc near ; CODE XREF: start+AF?p

.text:00401012
.text:00401012 var_38	= dword ptr -38h
.text:00401012 var_34	= byte ptr -34h
.text:00401012 var_24	= byte ptr -24h
.text:00401012 var_20	= byte ptr -20h
.text:00401012 var_10	= dword ptr -10h
.text:00401012 var_C	= dword ptr -0Ch
.text:00401012 var_8	= dword ptr -8
.text:00401012 var_4	= dword ptr -4

.text:00401012

щих обращений. Чаще всего данные	дый из промежуточных буферов, обя-
обрабатываются не сразу после прие-	зательно отслеживая их освобожде-
ма, а перегоняются через множество	ние (после освобождения локального
промежуточных буферов, каждый из	буфера принадлежащая ему область
которых может содержать ошибки пе-	памяти может быть использована кем
реполнения. Чтобы удержать ситуа-	угодно, вызывая ложные всплытия
цию под контролем, мы вынуждены	отладчика, отнимающие время и
устанавливать точки останова на каж-	сильно нервирующие нас). А ведь то-

hex-редактор под LINUX

ХАКЕРСПЕЦ 09(58) 2005

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w	p							o
							gчек останова всего четыре… Как же
	.							.c
			df			n		e
				-xcha

мы будем отслеживать обращения к десяткам локальных буферов с помощью всего четырех точек?

А вот как! Версия Soft-ice для Windows 9x поддерживает установку точки останова на регион, причем количество таких точек практически не ограничено. К сожалению, в Soft-ice для Windows NT эта вкусность отсутствует, и ее приходится эмулировать путем хитроумных манипуляций с атрибутами страниц. Переводя страницу в состояние NO_ACCESS, мы будем отлавливать все обращения к ней (в том числе и подопытному буферу). Естественно, если размер буфера много меньше размера страницы (как известно, он составляет 4 Кб), нам придется каждый раз разбираться, к какой именно переменной произошло обращение. При желании этот процесс можно полностью или частично автоматизировать (имеется множество

примочек к Soft-ice, поддерживающих развитые скриптовые языки).

Вот так дыры и ищутся! Минимум творчества, максимум рутины… Стрельбы и гонок по пересеченной поверхности здесь тоже нет. Тем не менее, сидеть в отладчике намного кру- че, чем смотреть "Матрицу" (кстати, никто не знает, где найти оригинальную версию третьей части, не изуве- ченную переводом?) или апгрейдить компьютер для игры в DOOM 3.

ЗАКЛЮЧЕНИЕ

Успех операции во многом зависит не только от опыта взломщика, но и пространственной ориентации монитора, геометрии мыши и степени потертости клавиатуры, а попросту говоря, от степени везучести. Поговаривают, что мыши и новые клавиатуры приносят несчастье: в самый ответственный момент курсор прыгает немного не туда и переполняющийся буфер остается незамеченным… E

Шпионаж за дисковыми операциями с помощью утилиты DiskMon от Марка Руссиновича

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

to

w Click

m

w

w

o

.

.c

p

g

df

n

e

-x cha

Soft-ice, запущенный под VMWare

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
	S E C U R I T Y - Ô Î Ê Ó Ñ Û			-xcha

34 КЛИЕНТ ЗАЩИТИСВОИПРИЛОЖЕНИЯ

Илья Рабинович

ЗАЩИТИ СВОИ ПРИЛОЖЕНИЯ

КАК ЗАЩИТИТЬСЯ ОТ АТАКИ НА ПЕРЕПОЛНЕНИЕ БУФЕРА

Ìногие люди задавали этот вопрос себе и окружающим. Очень возможно, что не раз. Да, защититься от атаки на переполнение буфера очень тяжело. Прежде всего потому, что этот класс атак мало формализован и крайне

изощрен. Но, тем не менее, если есть меч, то должен быть и щит!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

ЩИТ ¹1: ПАТЧИ ОТ » ПРОИЗВОДИТЕЛЯ

Универсальный метод. Если нет дыры, нет и атаки на нее.

Проблема состоит только в трех вещах. Первое: иногда после установки патча некоторые программы начинают работать неправильно. Соответственно, патчи нуждаются в предварительном тестировании, требующем времени. Второе: бывает так, что пат- чи закрывают дыру лишь частично. Третье: патчи выпускаются с большим (по компьютерным меркам) опозданием. Производителю нужно время на то, чтобы воспроизвести ситуацию у себя в тестовой лаборатории, переписать код, сделать патч, проверить этот патч на совместимость со своими программами и программами сторонних производителей. А пока эта работа идет, пользователь остается беззащитным. А на скольких дырках нет патчей, потому что производитель о них даже не догадывается?

ЩИТ ¹2: СИСТЕМЫ ОБНАРУЖЕНИЯ ВТОРЖЕНИЯ (INTRUSION DETECTION SYSTEM, IDS)

За этим названием скрываются программы, проводящие глубокий сигнатурный анализ сетевых пакетов на известные сигнатуры шелл-кодов. Если при этом анализе будет найдена сигнатура, соответствующая сигнатуре известного шелл-кода, пакет будет заблокирован и атака не достигнет цели. Самая известная подобная система распространяется как Open Source и называется Snort. Эта система очень распространена и популярна, к ней существует гигантское коли- чество сигнатур шелл-кодов, написанных энтузиастами и системными администраторами.

Недостатки подобных систем оче- видны. К ним относятся достаточно большое количество ложных срабатываний и неспособность определять те передаваемые по Сети шелл-коды, которые не известны системе. Более

того, поскольку часто шелл-коды передаются в зашифрованном виде, стоит сменить алгоритм шифрования даже у всем известного шелл-кода, и системы IDS уже перестают детектировать его. Насколько я знаю, ведутся работы над тем, чтобы IDS могли расшифровывать потенциальные шелл-коды на лету, но мне слабо верится, что в ближайшее время они будут способны на это. Короче говоря, позаимствовав технологию у антивирусов, IDS позаимствовали и их недостатки, прибавив к ним и свои собственные. Конечно, очень красиво с точки зрения маркетинга, что каждый раз, когда IDS ловит пакеты c Lovesan, выводится красивое окошечко: "Наша IDS защитила Вас от страшного и опасного вируса Lovesan". Во-первых, такое окошечко, выскакивающее каждые пять минут, уже через двадцать приводит в состояние нервного срыва, а во-вторых, какое реальное значение оно имеет на полностью пропатченной системе, не подверженной данной атаке? А при целенаправленной атаке на переполнение неизвестным для IDS шелл-кодом окошечко так и не выскочит...

ЩИТ ¹3: ФАЙРВОЛ

Работает по принципу "Если отрубить голову, то и насморка не будет".

Действительно, если сетевые пакеты с вредоносным кодом не смогут пройти к уязвимому приложению через отключенный с помощью файрвола порт, то буфер не будет переполнен и атака не состоится. Правда, «зафайрволенное» приложение фактически перестанет работать Много ли «насерфишь» в интернете, если файрволом отключен 80-й (HTTP) порт? Думаю, нет. А атак на переполнение буфера под Internet Explorer на моей памяти было много - от знаменитой "уязвимости в картинках" (переполнение буфера при рендеринге JPEG-изображений) до уязвимости в обработчике IFrame-ссылок. Отключа- ем 80-й порт?

ЩИТ ¹4: NX/XD-БИТ ПРОЦЕССОРА, ТЕХНОЛОГИЯ DEP ОТ MICROSOFT

Что же представляет собой этот широко разрекламированный бит? Все очень просто. NX - аббревиатура от Non-Executable. Бит неисполняемости процессора. Как известно, шелл-код внутри приложения имеет вполне определенное положение - это стек, куча или (очень-очень редко) статическая память внутри секции данных приложения. Если мы запрещаем выполнение кода внутри этих областей памяти (метим их NX-битом), то при попытке выполнить шелл-код в

Snort'у отдают предпочтение многие администраторы

ХАКЕРСПЕЦ 09(58) 2005

				hang		e
			C				E
		X
	-							d
	F									t
	D									i
										r
P						NOW!				o
					BUY
				to
w Click
											m
w
	w									o
	.						g		.c
		p
			df			n		e
				-xcha

Майкрософт о DEP. Конечно, на языке Шекспира

помеченных областях памяти мы получим исключение защиты. Все просто и гениально. Атака на переполнение не проходит.

Именно на основе NX/XD-бита и построена технология DEP от Microsoft, встроенная в операционные системы Windows XP SP2 и Windows 2003 SP1. Также технология DEP включает в себя контроль целостности стека и кучи на основе провероч- ных данных и контроль цепочки SEH.

Àтеперь - по порядку.

1.Внутри исполняемых процессов все области данных метятся NX-би- том, что запрещает исполнение кода в них. В случае попытки выполнить код в этих областях памяти вылетает исключение и приложение заканчивает свою работу. Если же процессор не поддерживает NX/XD-бит, то код можно выполнять в любой доступной области памяти процесса.

2.Контроль целостности стека представляет собой применение старой доброй технологии StackGuard, реализованной для Linux. При входе в функцию в стек запихивается некоторое проверочное число. При выходе из функции то число, которое лежит в стеке, сравнивается с эталонным. Если эти числа не совпадают, значит, было переполнение. В этом случае генерируется исключение защиты и приложение заканчивает свою работу. Эта возможность зало-

жена в компиляторы Microsoft начи- ная с VC 2003 (директива компилятора /GS, включена для всех проектов по умолчанию).

С кучей происходит примерно та же вещь: в начало каждого блока кучи операционная система помещает проверочные данные. Если при выделении нового блока или при освобождении старого где-то внутри цепочки блоков проверочные данные не сошлись, генерируется исключение защиты. Это не свойство компилятора, как в предыдущем случае, а свойство операционной системы!

3. Контроль целостности цепочки SEH. В общих словах, SEH - это последовательность обработчиков исклю- чений приложения. У каждого потока внутри приложения своя цепочка SEH! Если в потоке происходит исклю- чение, то система последовательно вызывает все обработчики, ожидая, что хоть один из них справится с ним. Если же ни один из обработчиков исключений не смог обработать его, то вызывается обработчик исключений, общий для всех потоков (UnhandledExceptionFilter). Если же и он бессилен, то системе ничего другого не остается, как показать сообщение "Ваш коврик от мышки выполнил недопустимую операцию и будет свернут..." и завершить данное приложение. Так вот, возвращаясь к контролю. При наличии исключения в потоке

35

система проверяет, не лежат ли адреса обработчиков исключений внутри кучи или стека. Если лежат, система генерирует исключение защиты.

И вроде бы все хорошо, все возможные пути проникновения в систему перекрыты. Так-то оно так, но не совсем. Исторически предтечи NX-бита появились на RISC-процессорах неIntell'овской архитектуры. Для них же впервые были созданы патчи на операционные системы, поддерживающие разграничение на исполнение кода внутри адресного пространства процесса. И именно для них появились первые "return-into-libc"- эксплойты за авторством Solar Desiner'а. Все гениальное просто. Если мы угадываем адрес системной функции, отвечающей за защиту страниц (оригинально исполняемые страницы модулей защищены от записи в них), и адрес функции копирования памяти из одного места в другое, мы можем скомпоновать данные при переполнении так, что при передаче управления первой его получит функция, отвечающая за защиту страниц с параметрами, которые позволят либо отключить защиту от записи в кодовую часть модулей, либо поставить атрибут "исполняемый" для какой-нибудь области памяти. После этого управление получает функция копирования с параметрами копирования нашего шелл-кода в уже подготовленную для исполнения область. Следующая часть Марлезонского балета: управление переходит на наш скопированный шелл-код в исполняемой области памяти. Как видишь, для реализации данного вида атаки необходимо: а) знать адреса функций; б) знать свой адрес; в) перехитрить проверки стека. И тут выясняется, что реализовать эти условия достаточно легко! Все необходимые функции для копирования памяти и управления параметрами защиты страницы реализованы в модуле kernel32.dll, база загрузки которого неизменна. Много угадывать не придется. Свой адрес мы можем также примерно знать, вбрасывая, например, большие порции данных 0x90 (команда nop) и шелл- »

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha				S E C U R I T Y - Ô Î Ê Ó Ñ Û

Линуксоиды о StackGuard'е		Целый номер Спеца, посвященный переполнению буфера!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
	S E C U R I T Y - Ô Î Ê Ó Ñ Û			-xcha

36 КЛИЕНТ ЗАЩИТИСВОИПРИЛОЖЕНИЯ

кодом в конце. А перехитрить проверку целостности стека можно таким образом: мы переполняем буфер большим пакетом данных так, чтобы переписать ближайший адрес обработчи- ка исключений SEH не просто, а чтобы он начал указывать внутрь какогонибудь модуля на нужную нам последовательность опкодов. Например, add esp,XXX, ret. Теперь, при выходе их функции, буфер внутри которой мы переполнили, обычно сначала выполняется восстановление из стека сохраненных регистров, после чего идет проверка целостности стека. И тут выясняется, что было переполнение. SOS! Выбрасывается исключение, которое ловит – правильно! - уже наш обработчик SEH. Инструкция add esp,XXX очистит стек от тех данных, которые туда вбросила система при вызове обработчика в цепочке SEH, а инструкция ret передаст управление по нужному нам адресу, который мы уже заботливо положили в стеке. Цепочка "return-into-libc" успешно выполнена! Защита рухнула! Так что не бывает непробиваемых защит - бывают только плохо изученные. Нужно учиться, и тогда никакая защита не устоит перед тобой. Описанный пример лишь учебный, полет фантазии при проектировании шелл-кодов не ограничен ничем.

Кстати, по умолчанию DEP включен только для компонентов операционной системы. Для программ сторонних разработчиков он выключен! Поче- му? Да потому что огромное количе- ство программ выполняют свой код в куче или стеке, и часто даже без ведома самих разработчиков! Как такое может быть? Очень просто! При сабклассинге библиотека ATL помещает специальную функцию-переходник в кучу или стек и ставит на нее адрес обработчика оконной функции. В итоге при любом вызове оконной функции, перехваченной таким образом, сначала вызывается переходник в ку- че или стеке, который, в свою оче- редь, вызывает обработчик оконной функции, уже написанный разработ- чиком. И таких программ довольно много (навскидку, из известных - VMWare).

Если же процессор не обладает NX/XD-битом, то тут дело совсем плохо: как все только что убедились, защита от переполнения буфера от Microsoft тянет хоть на что-то только при наличии NX/XD-бита. Без него предыдущий пример был бы еще проще и "return-into-libc"-технологии были бы не нужны. Ставим обработчик ошибок SEH на заранее найденную инструкцию jmp [esp+8]-, и шелл-код зашуршал своими байтиками и опкодами в обход всех защит. И отсюда следует....

Неидеальный Cisco Security Agent

ЩИТ ¹5: ЗАЩИТА ОТ СТОРОННИХ РАЗРАБОТЧИКОВ

Рассмотрим наиболее известные продукты - DefencePlus, Cisco Security Agent, StackDefender, OverflowGuard - в обратном порядке (по возрастанию уровня сложности программ порядок именно такой).

OverflowGuard защищает только сервисы Microsoft Windows. Защита строится на неисполняемости стека и кучи. Правда, в отсутствие NX/XD-би- та эта неисполняемость достается дорого - ценой производительности системы. Именно поэтому OverflowGuard защищает только сервисы: чем меньше защищаемых приложений, тем меньше падение производительности. Защита декларируется от return- into-libc, но проверить это на практике очень тяжело. Прогнать тесты на софте, который защищает систему ТАК, практически нереально. Кроме того, если учесть, что акценты атак на переполнение буфера сегодня смещаются в сторону программ не от Microsoft, эта программа вообще ни от чего, собственно, не защищает.

Cisco Security Agent базируется на перехвате вызовов функций, то есть если наш шелл-код вызывает функцию StartService, этот вызов будет перехвачен обработчиком от Cisco и проанализирован на адрес возврата из функции. Этот адрес должен ле-

					hang		e
				C				E
		X
	-								d
	F									t
	D									i
										r
P							NOW!			o
						BUY
					to
			Click
w											m
w
	w									o
	.								.c
		p						g
				df			n		e
					-x cha

жать внутри модуля, и перед ним должна быть инструкция call [что-ни- будь] или jmp [что-нибудь].

Эти проверки обходятся также элементарно. Достаточно при вызове функций, перехваченных CSA, подставлять не свой адрес возврата, а адрес конструкции:

call [неважно_что]/jmp [неважно_что]

fake_addr: <-этот адрес мы подставляем как адрес возврата! здесь какой-то код, который не будет мешать нам получить результат

ret. <-а здесь в стеке должен оказаться наш реальный адрес возврата!

StackDefender в своей обычной модификации (есть еще Server Edition) также базируется на защите на основе неисполняемых стека и кучи для базовых сервисов операционной системы и на перехвате вызовов функций для всех приложений (в том числе для сервисов). Кроме того, программа изменяет базовый адрес для модуля kernel32.dll, но не рандомизирует эту базу при каждой перезагрузке, то есть при каждой перезагрузке она хоть и смещена относительно стандартной, но не меняется при этом.

Все эти программы в случае обнаружения атаки завершают весь процесс целиком, и для защиты, например, web- и ftp-серверов они непригодны.

DefencePlus базируется также на технологии неисполняемости стека и

Softsphere.com – качаем и наслаждаемся разными версиями DefencePlus

ХАКЕРСПЕЦ 09(58) 2005

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click
										m
w
	w								o
	.						g		.c
		p
			df			n		e
				-xcha

StackDefender в процессе работы

кучи, но эта технология уникальна тем, что практически не приводит к падению производительности защищаемой системы, поэтому защищаются все процессы в системе.

Для совместимости с программами, выполняющими свой код в куче или стеке (а их немало), у программы есть четыре уровня защиты, которые позволяют добиться максимальной совместимости с уже написанным ПО. По умолчанию все процессы защищаются так, что стек неисполняем, а куча исполняема. В этом случае защита ку- чи базируется на контроле точек перевода управления на эксплойт в ку- че. Дело в том, что этих точек немного: ячейка памяти с адресом UnhandledExceptionFilter, ячейки памяти в TEB (системная база данных потока) с адресами функций RtlAcquirePebLock/RtlReleasePebLock и SEH. Если контролировать целостность критически важных ячеек памяти и SEH, то можно добиться хорошего уровня защиты кучи, сохранив ее исполняемость. Кроме неисполняемости, контроля целостности SEH и точек перевода управления, программа случай-

ным образом перемешивает данные в куче и стеке для предотвращения угадывания адресов, где лежат шелл-ко- ды, случайным образом перемещает базовые библиотеки при каждой перезагрузке, чем чрезвычайно затрудняет "return-into-libc"-атаку (попробуй догадайся, куда программа забросила базу kernel32.ddl в этот раз!). В случае атаки завершается не все приложение, а только атакованный поток, что делает ее пригодной для защиты web- и ftpсерверов. Единственная проблема программы - это совместимость с KAV под Windows 2000.

ЧТО ДЕЛАТЬ, ЕСЛИ МЕНЯ УСПЕШНО АТАКОВАЛИ?

Прежде всего - не впадать в панику. Команда "format c:" - это крайняя мера. Во-первых, нужно установить все последние заплатки от производителя ОС. Во-вторых, желательно помнить, что шелл-код, если он небольшой, не способен серьезно повредить систему. Ему необходимо выкачать из Сети дополнительные компоненты. Сделать это он может или с помощью tftp (простой ftp-модуль,

37

входящий в стандарт поставки операционной системы), или с помощью Internet Explorer. И тут мы способны перехватить и заблокировать эти действия с помощью файрвола. Вообще хороший файрвол как утилита защиты после взлома незаменим, и именно поэтому грамотно спроектированный шелл-код будет любыми способами противодействовать файрволу - от попыток обмануть его и выкачать свои компоненты тихо и незаметно до попыток выгрузить файрвол и отключить защиту.

Если же шелл-код достаточно велик, чтобы самостоятельно создать исполняемый модуль на диске, то у жертвы атаки море планов действий - от установки этого модуля как реверсивного трояна до попыток установить руткит. Если антивирус, установленный на компьютере, не будет иметь этот модуль в своей антивирусной базе, он пропустит его. В этом случае понадобятся утилиты типа AVZ (неплохой антируткит, построение списка загружаемых модулей - www.z-oleg.com), HijackThis (построение списка загружаемых модулей - www.tomcoyote.org/hjt). Люди, которые не в состоянии самостоятельно справиться с логами этих программ, могут обратиться на неплохой русскоязыч- ный ресурс www.virusinfo.info: запостить логи и при этом вполне рассчитывать на бескорыстную помощь.

Что же делать, если ничего не помогло? Полностью переустановить операционную систему, поставить на нее файрвол, антивирус и защиту от атак на переполнение буфера, выка- чать и установить все заплатки.

Сегодня атаки из массовых превращаются в акцентированные и целенаправленные, а хакерская вольница постепенно перевоплощается в многомиллионный бизнес, в котором зомбируют тысячи компьютеров и крадут номера кредиток миллионами. В таком мире безопасности никогда не бывает слишком много. Недостаточно - бывает, много - нет. Поэтому я призываю всех набираться опыта и знаний, в том числе в области компьютерной безопасности. Без этого будет очень тяжело противостоять коммерциализующейся армии взломщиков. E

				hang		e
			C				E
		X
	-							d
	F								t
	D								i	r
P						NOW!			o
					BUY
				to
w Click											m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha				S E C U R I T Y - Ô Î Ê Ó Ñ Û

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
	S E C U R I T Y - Ô Î Ê Ó Ñ Û			-xcha

38 КЛИЕНТ ВСЯПРАВДАОБАНТИВИРУСАХ

Андрей Семенюченко ([e-mail])

ВСЯ ПРАВДА ОБ АНТИВИРУСАХ

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

ОБЗОР И АНАЛИЗ САМЫХ ПОПУЛЯРНЫХ АНТИВИРУСОВ

Ñовременный IT-рынок предлагает огромный ассортимент защитного программного обеспечения. Как разобраться во всем разнообразии антивирусов, одновременно не утонув в море информации? Чей антивирус лучше? Всегда ли

производители говорят правду о своих продуктах? Существуют ли слабые места у этого вида ПО? На эти и многие другие вопросы постараюсь осветить в этой статье.

ОРГАНИЗАЦИЯ » И ТЕХНОЛОГИЯ ЗАЩИТЫ ИНФОРМАЦИИ

Построение защищенной компьютерной системы – это целая наука, и полностью охватить ее вряд ли возможно в рамках одной статьи. Для этого следовало бы рассмотреть целый комплекс организационных, правовых, экономических, ин- женерно-технических, программно-ап- паратных методов и средств защиты компьютерной обработки информации. Даю установку - рассмотреть лишь часть средств защиты, а именно антивирусные программы.

На самом деле информационная безопасность - это защита информации

èзащита от информации. Действительно, почти все организации, имеющие доступ к небезопасным соединениям, применяют межсетевые экраны

èантивирусы, которые прекрасно со- четаются между собой. Задача файрволов – фильтровать входящий и исходящий трафик для защиты системы на уровне протоколов и приложений. Задача антивирусного ПО – анализировать входящие/исходящие данные. Другими словами, система защиты

строится на блокировке неиспользуемых и потенциально опасных протоколов и приложений межсетевым экраном, а вся оставшаяся разрешенная входящая/исходящая информация фильтруется антивирусом.

ПЕРЕЧЕНЬ ПРОДУКТОВ

На российском рынке представлено около десятка межсетевых экранов. С антивирусами дело обстоит гораздо сложнее, поскольку каждый бренд представляет более десятидвадцати наименований продуктов. Так, самый популярный российский антивирус, Антивирус Касперского, имеет в своем арсенале более пяти наименований продуктов в категории

Антивирус Касперского

Защита от настоящих и будущих угроз

Dr.Web

"Для домашних пользователей" и более пятнадцати - класса "Для корпоративных клиентов". Разумеется, привести, описать и сравнить все приложения просто невозможно. Поэтому более эффективным методом является сравнение антивирусных программ, входящих в состав корпоративных пакетов, - сопоставление возможностей и услуг, предоставляемых каждой компанией-производителем. Так будет даже интереснее. Больше достоинств – больше недостатков! На наш суд представлены следующие антивирусы: Kaspersky Business Optimal,

Ñàéò AV-comparatives

Ñàéò AV-Test GmbH

ХАКЕРСПЕЦ 09(58) 2005